FireBird a trigger
Otázka od: Rostislav Lekes
3. 12. 2003 11:15
Cau,
mam problem s triggerem before update:
potrebuju, aby zavolal vyjimku a neprovedl update, kdyz tento update nebude
z programu, ale nejak pokoutne 
, treba z IBExperta.
Da se to nejak vyresit? Napadaji me dve moznosti, ale ani jednu nevim, jak
zprovoznit.
1) Zjistit v triggeru stupen (level) vnoreni. Tzn., ze by update mohli
provadet jen stored procedury. Kdyz bude level >1 (0) tak by se volala
vyjimka. Ale nevim, jestli firebird (1.0.x) neco takoveho umi.
2) Zjistit, jestli se v update aktualizuji vsechny predepsane fieldy, ale to
taky nevim jak udelat. if old.xxx<>new.xxx pro vsechny tyto fieldy me
nepomuze, protoze nektere povinne fieldy muzou mit novou hodnotu stejnou
jako starou.
Tak co s tim, vite nekdo? Diky.
Rostislav Lekes
Odpovedá: BRCKO Peter
3. 12. 2003 12:09
> mam problem s triggerem before update:
> potrebuju, aby zavolal vyjimku a neprovedl update, kdyz tento
> update nebude
> z programu, ale nejak pokoutne , treba z IBExperta.
Da sa to vyriesit vseobecne na lubovolnej databaze.
Urcite pri plnom pristupe do databazy je tato "OCHRANA"
jednoducho prelomena ale v opacno pripade je to O.K.
Na FB to nemam vyskusane, takze iba ako napad.
( V Oracle su tzv PACKAGE, ktore maju jednu vybornu vlastnost
a to, ze hodnoty premennych v nich definovane su jednoznacne pre kazdeho
uzivatela. Potom staci tuto premennu nastavit, kontrolovat v triggroch
a na zaklade nej rozhodovat o povoleni zapisu do tabulky/tabuliek. Podstatne
je ze ich Oracle inicializuje - podla ich definicie - pre kazdu session zvlast.
Staci nastavit defaultne nedovoleny zapis a povolit to programovo.)
Potrebujes jednoznacne pomoc od FB. Idelane je odchytit connect do DB.
Nadefinujes tabulku v ktorej bude primarnym klucom jenoznacny udaj pre kazdy
connect, t.j. asi session a kontrolovanu premennu nadobudajucu dve hodnoty
Y/N. Kazdy BI, BU, BD trigger na tabulke moze kontrolovat povolenie
zapisu. Pri Connecte zapises do DB jeden zaznam s default hodnotou N.
Z aplikacie (popripade aj pri rucnom / scriptom spracovani) tuto hodnotu
nastavis na Y. To je vsetko.
P.S. Toto riesenie ma jednu nevyhodu a to cistenie tejto tabulky pre neaktivne
sessny.
Ale to by nemalo byt prekazkou. Napr. uzavierky by to mohli cistit.
A mozno existuje vo FB podobne jednoduche riesenie ako v Oracle,
no na to su potrebne hlbsie vedomosti o FB ako moje.
Peter Brcko.
Odpovedá: Jirka
3. 12. 2003 12:52
Ahoj,
nevim sice na co to potrebujes, ale slo by to tak ze by jsi v te
procedure vlozil urcity zaznam do tabulky a v tom trigru kontroloval
jestli tam je. Kdyz tam nebude tak hodit Exception.
Jeste budes muset ale vyresit problem s viceuzivatelkym pristupem 
Jirka
Rostislav Lekes wrote:
> Cau,
> mam problem s triggerem before update:
> potrebuju, aby zavolal vyjimku a neprovedl update, kdyz tento update nebude
> z programu, ale nejak pokoutne , treba z IBExperta.
> Da se to nejak vyresit? Napadaji me dve moznosti, ale ani jednu nevim, jak
> zprovoznit.
> 1) Zjistit v triggeru stupen (level) vnoreni. Tzn., ze by update mohli
> provadet jen stored procedury. Kdyz bude level >1 (0) tak by se volala
> vyjimka. Ale nevim, jestli firebird (1.0.x) neco takoveho umi.
> 2) Zjistit, jestli se v update aktualizuji vsechny predepsane fieldy, ale to
> taky nevim jak udelat. if old.xxx<>new.xxx pro vsechny tyto fieldy me
> nepomuze, protoze nektere povinne fieldy muzou mit novou hodnotu stejnou
> jako starou.
>
> Tak co s tim, vite nekdo? Diky.
Odpovedá: Radek KALA
3. 12. 2003 12:48
To se da udelat jinak, nedas uzivateli prava na update te tabulky.
> Ahoj,
> nevim sice na co to potrebujes, ale slo by to tak ze by jsi v te
> procedure vlozil urcity zaznam do tabulky a v tom trigru kontroloval
> jestli tam je. Kdyz tam nebude tak hodit Exception.
>
> Jeste budes muset ale vyresit problem s viceuzivatelkym pristupem
>
> Jirka
>
> Rostislav Lekes wrote:
> > Cau,
> > mam problem s triggerem before update:
> > potrebuju, aby zavolal vyjimku a neprovedl update, kdyz tento update
> > nebude z programu, ale nejak pokoutne , treba z IBExperta. Da se
> > to nejak vyresit? Napadaji me dve moznosti, ale ani jednu nevim, jak
> > zprovoznit. 1) Zjistit v triggeru stupen (level) vnoreni. Tzn., ze
> > by update mohli provadet jen stored procedury. Kdyz bude level >1
> > (0) tak by se volala vyjimka. Ale nevim, jestli firebird (1.0.x)
> > neco takoveho umi. 2) Zjistit, jestli se v update aktualizuji
> > vsechny predepsane fieldy, ale to taky nevim jak udelat. if
> > old.xxx<>new.xxx pro vsechny tyto fieldy me nepomuze, protoze
> > nektere povinne fieldy muzou mit novou hodnotu stejnou jako starou.
> >
> > Tak co s tim, vite nekdo? Diky.
>
>
>
>
>
S pozdravem Radek KALA
BetaControl, s.r.o.
Cerneho 58/60, 635 00
tlf. : + 420 5 4622 3491
fax : + 420 5 4622 3470
GSM : + 420 603 85 75 15
Odpovedá: BRCKO Peter
3. 12. 2003 13:26
> To se da udelat jinak, nedas uzivateli prava na update te tabulky.
Ale ten uzivatel ma prava na update bud do T alebo V lebo je to aplikacny
uzivatel,
ale ma ja lubovolny nastroj na aktualizaciu FB a tym padom ma connect do Tvojej
DB.
Potrebujes mu zabranit priamu aktualizaciu dat a tento postup Ti v tom ma
pomoct.
Peter Brcko.
Odpovedá: Rostislav Lekes
3. 12. 2003 13:50
> To se da udelat jinak, nedas uzivateli prava na update te tabulky.
Jasne, to by bylo idealni. Moje chyba, asi jsem spatne popsal problem.
Upresnim to.
na firebird pristupuje v beznem provozu pouze aplikacni server jako sysdba.
Clienti se na db vubec nedostanou.
Jde o to, aby nasi obchodaci a zrucnejsi uzivatele-zakaznici, kteri maji
fyzicky pristup k serveru, nemohli bez kontroly provadet nejake prasarny.
> nevim sice na co to potrebujes, ale slo by to tak ze by jsi v te
> procedure vlozil urcity zaznam do tabulky a v tom trigru kontroloval
> jestli tam je. Kdyz tam nebude tak hodit Exception.
>
> Jeste budes muset ale vyresit problem s viceuzivatelkym pristupem
tohle je lepsi napad, ale stejne me nepomuze, protoze applikacni server muze
vytvorit x connect do FB pod stejnym userem a pak bych se v tom nevyznal
Odpovedá: Pavel Cisar
3. 12. 2003 14:41
Haj hou!
On 3 Dec 2003 at 13:35, Rostislav Lekes wrote:
> > To se da udelat jinak, nedas uzivateli prava na update te tabulky.
>
> Jasne, to by bylo idealni. Moje chyba, asi jsem spatne popsal problem.
> Upresnim to.
> na firebird pristupuje v beznem provozu pouze aplikacni server jako sysdba.
> Clienti se na db vubec nedostanou.
> Jde o to, aby nasi obchodaci a zrucnejsi uzivatele-zakaznici, kteri maji
> fyzicky pristup k serveru, nemohli bez kontroly provadet nejake prasarny.
1) Pracovat s produkcni databazi standardne jako SYSDBA je prasarna,
a uz z principu vylucuje nejake zabezpeceni. A vubec nezalezi na tom,
ze jako SYSDBA se prihlasuje program.
Pokud je duvodem snaha vyhnout se nastavovani prav, pak zalozte
specialniho "aplikacniho" uzivatele a vytvorte pod nim databazi. Tak
se stane vlastnikem vsech objektu a dat, a nemusite nic nastavovat.
2) Pokud se nikdo nepovolany nemuze prihlasit jako SYSDBA, lze
pristupova opravneni resit standardne, a neni treba vymyslet
komplikace s triggery.
3) Pokud potrebujete rozlisovat realne uzivatele schovane za jednim
db uzivatelem (napr. skrze middleware), pouzijte sql role.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: BRCKO Peter
3. 12. 2003 14:35
> 2) Pokud se nikdo nepovolany nemuze prihlasit jako SYSDBA, lze
> pristupova opravneni resit standardne, a neni treba vymyslet
> komplikace s triggery.
Takto ale nezabranim vynimocnej situacii, ktora moze nastat, ked niekto
so znalostou DB a pravami aplikacneho uzivatela sa dostane lubovolnym
nastrojom na DB a moze poskodit minimalne koexistentnost dat
(cast alebo cela aplikacna logika je na Clientovi).
Asi mal dotazovatel s podobnymi zasahmi skusenosti, ked sa zamyslal nad
tymto problemom.
Pri DB s obrovkym poctom tranzakcii / s by jeden dotaz navyse mohol zbytocne
natahovat
odozvy ale pre aplikacie, kde ide aj o takyto stupen bezpecnosti by som to
doporucoval.
Peter Brcko.
Odpovedá: Vlastimil Bardon
3. 12. 2003 14:45
FireBird neznam, ale na MS SQL existuji tyto moznosti (a cekal bych, ze
FireBird bude mit nejako analogie)
1) Nepovolis NIKOMU update te tabulky, ale udelas si proceduru na tento update
a das prava uzivatelum na tuto proceduru. Uzivatelum nereknes ktera procedura
to meni a pokud nejsou presprilis sikovni, tak na to neprijdou a proto tabulku
nezmeni
2) Existuji tzv Aplikacni role. Aplikace se sice prihlasi k DB jako konkretni
uzivatel, ale pak se prepne do aplikacni role (ke ktere nebude znat heslo nikdo
jiny, nez Ty). Pravo na update tabulky das jen te aplikacni roli a nikoli
konkretnimu uzivateli. Pak je uzivatel bez sance cokoli zmenit jinou cestou,
nez pomoci aplikace. (Pritom server pri chodu aplikace stale vi, s kym ma tu
cest)
-----Original Message-----
From: Rostislav Lekes [mailto:rlekes@atlas.cz]
Sent: Wednesday, December 03, 2003 1:36 PM
> To se da udelat jinak, nedas uzivateli prava na update te tabulky.
.... ale stejne me nepomuze, protoze applikacni server muze
vytvorit x connect do FB pod stejnym userem a pak bych se v tom nevyznal
Odpovedá: Rostislav Lekes
3. 12. 2003 15:30
----- Original Message -----
From: "Pavel Cisar" <pcb@atlas.cz>
To: <delphi-l@clexpert.cz>
Sent: Wednesday, December 03, 2003 2:03 PM
Subject: Re: FireBird a trigger
> Haj hou!
> 1) Pracovat s produkcni databazi standardne jako SYSDBA je prasarna,
> a uz z principu vylucuje nejake zabezpeceni. A vubec nezalezi na tom,
> ze jako SYSDBA se prihlasuje program.
Jasne ze je to prasarna a ted delame na predelavkach. Konecny stav by mel
byt takovy, ze appserver bude mit sveho usera, ktery bude mit pravo pouze
spoustet ulozene procedury, bez primeho pristupu k datum. SYSDBA budeme
eliminovat (zmena hesla a zakaz pouzit k programovemu pristupu).
> Pokud je duvodem snaha vyhnout se nastavovani prav, pak zalozte
> specialniho "aplikacniho" uzivatele a vytvorte pod nim databazi. Tak
> se stane vlastnikem vsech objektu a dat, a nemusite nic nastavovat.
>
> 2) Pokud se nikdo nepovolany nemuze prihlasit jako SYSDBA, lze
> pristupova opravneni resit standardne, a neni treba vymyslet
> komplikace s triggery.
Tady o to presne jde. Oni se rucne k datum obcas potrebuji dostat a zakazat
uplne to proste nejde, i kdyz by to bylo nejlepsi. Protoze nelze predem ani
definovat, kam presne muzou a kam ne, nelze jim ani udelat prislusny ucet.
Ale protoze zname operace, ktere se jim musi zakazat, napadlo nas resit to
triggrem. Oni muzou v konkretni tabulce udelat UPDATE, ale ne jakykoliv.
Proto jsem napsal tento dotaz, nechtel jsem resit bezpecnost FB. Stejne tak
dobre vim, ze se ten trigger nauci vypinat , takze z toho duvodu jim mozna
specialni ucet vytvorime.
> 3) Pokud potrebujete rozlisovat realne uzivatele schovane za jednim
> db uzivatelem (napr. skrze middleware), pouzijte sql role.
To nepotrebujeme, resp.je mame rozlisene na appserveru a to nam staci.
Rosta
Odpovedá: Pavel Cisar
3. 12. 2003 16:06
Haj hou!
On 3 Dec 2003 at 14:19, BRCKO Peter wrote:
> > 2) Pokud se nikdo nepovolany nemuze prihlasit jako SYSDBA, lze
> > pristupova opravneni resit standardne, a neni treba vymyslet
> > komplikace s triggery.
>
> Takto ale nezabranim vynimocnej situacii, ktora moze nastat, ked niekto
> so znalostou DB a pravami aplikacneho uzivatela sa dostane lubovolnym
> nastrojom na DB a moze poskodit minimalne koexistentnost dat
> (cast alebo cela aplikacna logika je na Clientovi).
Pro definici odlisnych opravneni v aplikaci a v "jinem nastroji" jsou
dva standardni scenare:
1) uzivatel nezna uzivatelsky ucet kterym s k db prihlasuje aplikace,
ale pouziva nejaky jiny, ktery ma prislusne omezena opravneni.
2) uzivatel sice zna a pouziva ucet ktery pouziva aplikace, ale nezna
roli, kterou aplikace pouziva. V takovem pripade pridelim prava
aplikacni roli a nikoliv primo uzivatelskemu uctu.
IMO jednodussi je metoda 1.
Samozrejme se predpoklada, ze uzivatel nemuze pouzit ucet SYSDBA.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Pavel Cisar
3. 12. 2003 16:31
Haj hou!
On 3 Dec 2003 at 14:57, Rostislav Lekes wrote:
> Tady o to presne jde. Oni se rucne k datum obcas potrebuji dostat a zakazat
> uplne to proste nejde, i kdyz by to bylo nejlepsi. Protoze nelze predem ani
> definovat, kam presne muzou a kam ne, nelze jim ani udelat prislusny ucet.
> Ale protoze zname operace, ktere se jim musi zakazat, napadlo nas resit to
> triggrem.
Ok, chapu. problem je v tom, ze nevite co povolit, ale vite co
zakazat. SQL security schema s opacnym pristupem se vam tedy moc
nehodi. Souhlasim, ze je vhodne to udelat pres before trigger s
vyjimkou. nejjednodussi postup je ale stejne pres vytvoreni
samostatneho uctu (nebo role) pro takove pouziti. Prava sice
pridelite vsechny, ale v triggerech si otestujete pres current_user
nebo current_tole kdo je na drate a pripadne vyvolate vyjimku.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase